home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 450 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.7 KB

  1. Path: newshost.lanl.gov!tanmoy
  2. From: tanmoy@qcd.lanl.gov (Tanmoy Bhattacharya)
  3. Newsgroups: comp.std.c
  4. Subject: Re: sizeof(char) ~= sizeof(float)
  5. Date: 26 Feb 1996 03:35:14 GMT
  6. Organization: Los Alamos National Laboratory
  7. Message-ID: <TANMOY.96Feb25203514@qcd.lanl.gov>
  8. References: <WALD.96Feb24131532@woodpecker.lcs.mit.edu> <4gr3d1$dca@usenet.pa.dec.com>
  9. NNTP-Posting-Host: qcd.lanl.gov
  10. Mime-Version: 1.0
  11. Content-Type: text
  12. In-reply-to: diamond@tbj.dec.com's message of 26 Feb 1996 01:46:09 GMT
  13.  
  14. In article <4gr3d1$dca@usenet.pa.dec.com>
  15. diamond@tbj.dec.com (Norman Diamond) writes:
  16. <snip>
  17. ND: Rumor has it that Technical Corrigendum 2 will change the standard so that
  18. ND: unsigned char cannot have any holes.  Signed char will still be allowed to
  19. ND: have holes, and char will still have to behave either as unsigned char (no
  20. ND: holes) or as signed char (identical holes).
  21.  
  22. What happens to the requirement that positive signed integral values
  23. have to have the same representation as the corresponding unsigned
  24. integral value? Coupled with the requirement of pure binary
  25. representation (I am not sure what `pure binary' means: assuming it
  26. means that only one bit can represent the sign), it seems to say that
  27. if unsigned char can't have holes, neither can signed char unless
  28. whether a certain bit contributes to the value or not depends on the
  29. sign bit; I assume such `holes' are allowed?
  30.  
  31. ND: 
  32. ND: >The basic argument against, presented by Tanmoy Bhattacharya, is that
  33. ND: >memory compare, and possibly memory copy functions, can't be implemented
  34. ND: >in a portable fashion if two dissimilar regions of memory can't be
  35. ND: >distinguished by comparing them char-wise.
  36. ND: 
  37. ND: Is that really what he said?  I'm sure Mr. Bhattacharya knows many parts
  38. ND: of the standard which cannot be implemented in a portable fashion.  Every
  39. ND: implementation has to provide some degree of portability to some kinds of
  40. ND: programs -- that is what the standard requires -- but an implementation
  41. ND: itself does not port so easily.  So, what is one more minor grunge?
  42. ND: 
  43.  
  44. No, that was not the argument. I was assuming that the rumored TC2
  45. interpretation will be adopted. The argument is that in 
  46.  
  47. float x, y;
  48. unsigned char *xx=(void*)&x, *yy=(void*)&y;
  49.  
  50. copying (or comparing) sizeof(float) unsigned chars from xx to yy must
  51. manage to copy (or compare) x from y.
  52.  
  53. The suggestion to post to comp.std.c was precisely because this was a
  54. rumor, and people in this group are more likely to know whether I have
  55. got the gossip right :-)
  56.  
  57. <snip>
  58. ND: If you assign one char to another using an assignment operator, it doesn't
  59. ND: have to do so.  (Except of course that after TC2, if you use
  60. unsigned chars, 
  61. ND: then there can't be hidden bits any more.)
  62.  
  63. Whether or not `char' can have holes, if there are say two
  64. representations of 0 (sign-magnitude / one's complement etc.) a copy
  65. of char can change one representation to the other.
  66.  
  67. ND: 
  68. ND: If you use memcpy or possibly if you play tricks with union types, you can
  69. ND: force it to copy all the bits.
  70.  
  71. This was a free-standing implementation, and memcpy may be absent. (In
  72. a hosted implementation, as all read/write is done as if through
  73. getc/putc which handles unsigned char values, and binary files written
  74. out must be read back unchanged, the situation is impossible).
  75.  
  76. Cheers
  77. Tanmoy
  78. --
  79. tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
  80. Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
  81. Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
  82. <http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
  83. internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
  84. fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]
  85.